As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an Information Handling System (IHS). An IHS generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, IHSs may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in IHSs allow for IHSs to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, global communications, etc. In addition, IHSs may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
In most IHSs, low-level code is used as an intermediary between hardware components and the Operating System (OS), as well as other high-level software. In some IHSs, this low-level code is known as the Basic Input/Output System (BIOS). The BIOS provides a set of software routines that allow high-level software to interact with hardware components using standard calls. Because of certain limitations of the original BIOS, a new specification for creating code that is responsible for booting the IHS has been developed that is called the Extensible Firmware Interface (EFI) Specification, and which has been extended by the Unified Extensible Firmware Interface Forum (UEFI).
The EFI Specification describes an interface between the OS and the system firmware. In particular, the EFI Specification defines the interface that platform firmware must implement and the interface that the OS may use in booting. The EFI Specification also specifies that protocols should be provided for EFI drivers to communicate with each other. An EFI protocol is an interface definition provided by an EFI driver. The EFI core provides protocols for allocation of memory, creating events, setting the clock, etc.
UEFI Secure Boot is an industry-standard mechanism in the system BIOS for authenticating pre-boot code modules (e.g., device drivers or other software or firmware code). The UEFI specification defines data structures and logic for the authentication process. The BIOS maintains a Secure Boot policy having X.509 certificates, public keys, and image digests. The BIOS enforces the Secure Boot policy for each pre-boot code module that loads during the boot process. If a pre-boot code module cannot be authenticated or does not otherwise satisfy the Secure Boot policy, the BIOS does not load that module.
The majority of pre-boot code modules in use today include I/O device firmware and OS boot loaders, which are signed by a single third-party certificate authority (CA). The inventors hereof have recognized, however, that it would be of great benefit to customers and developers to be able to use their own signing keys to sign pre-boot code modules, especially customers who are looking for secure cloud solutions, instead of trusting a third-party CA.
Conventional platforms offer a mechanism for removing default keys from the Secure Boot policy and importing custom keys. However, the inventors hereof have also recognized that using custom keys is relatively simple for OS boot loaders, but very difficult for device firmware. Particularly, OS boot loaders can be signed and then copied to the EFI System Partition. But, for I/O device firmware, customers need a way to obtain each firmware image they want to sign, and, after signing, those customers need a secure way to install the signed images back onto the devices.
A traditional solution to the foregoing problem is for the customer (or the Original Equipment Manufacturer or “OEM”) to work with each supplier directly to obtain the supplier's UEFI firmware image in PE/COFF format (required by Secure Boot signature verification). Each supplier then also provides a secure mechanism to update the device with firmware images signed by the customer.
The inventors hereof have recognized, however, that the traditional solution is undesirable for many reasons. Particularly, the large number of components and firmware used by the various devices in any modern IHS creates a need for each customer to interact with a large number of device suppliers, which increases deployment and maintenance time.